feat: @deck.gl-community/json — Zod schemas for GeoJSON (Step 1 of #596)#597
feat: @deck.gl-community/json — Zod schemas for GeoJSON (Step 1 of #596)#597charlieforward9 wants to merge 3 commits into
Conversation
Adds a vocabulary of Vercel AI SDK v4-shaped tools for editable-layers. Each tool has description + Zod-validated parameters + execute() that mutates a FeatureCollection immutably. Ships draw_point (full impl) and 10 further tools (scaffold stubs returning not_implemented). Includes a compliance test that exercises draw_point via direct-geom and mode-replay paths, proving the factory contract. 2 pre-existing zod internal test failures excluded (missing optional dev deps recheck and @web-std/file — not part of our code). Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
New module @deck.gl-community/json: Zod schemas for all GeoJSON spec primitives (Position, Point, LineString, Polygon, Multi*, GeometryCollection, Feature, FeatureCollection). Each schema exports the Zod schema value and its inferred TypeScript type. Zero runtime deck.gl dependency. Refactored editable-layers ai-tools: draw-point, draw-polygon, draw-line-string, modify-feature, rotate-feature, split-polygon import PositionSchema from @deck.gl-community/json instead of hand-rolling z.tuple([z.number(), z.number()]). Public API and compliance test unchanged. Fixed vitest.config.ts: added modules/**/node_modules/** exclusion to prevent zod internal test files from being picked up by the runner. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
|
My preference would be to land the new module with the schemas separately, and then open another PR with any changes you want to do in editable layers. Generally, my view is that the json module should be an optional module that users import when they want to add a JSON support, we will likely add a lot of stuff to that module, other modules like editable layers should not import it. For something like a GeoJSON zod schema, that could potentially go into a loaders.gl module. |
|
just passing by, but surely this can be achieved without tying consumers to a specific zod version (or zod in general)? I'd like to understand the version selected here - I'm not sure how this will play out for anyone using v4 since a lot of deprecations are being used. strictly speaking, some of the while I understand this is an experimental package, I don't think it's a good idea to bake in a specific validator. why not export Standard Schema / Standard JSON Schema and let the consumers use a validator of their choice? sorry if this sounds negative, it's not my intention. I truly appreciate the hard work you maintainers are putting in 🤝 ❤️ |
charlieforward9
force-pushed
the
ai_json-schemas-and-edit-tools
branch
from
128efe9 to
3d996d8
Compare
CoverageStmts: 50.84% ▲+0.02% | Branch: 41.92% | Funcs: 49.22% ▲+0.02% | Lines: 50.97% ▲+0.02%
|
3 participants
Summary
Related to #596.
This narrows the PR to the optional
@deck.gl-community/jsonmodule only:Validation
yarnyarn lintyarn lint-fixyarn test-node modules/json/src/test/geojson.test.tsyarn test: 164 files passed, 1423 tests passed, 9 skippedyarn buildcd website && yarn && yarn buildManual verification
Notes
This keeps the module validator-specific for now because the existing PR and tests are built around Zod schemas, but it aligns with the repo's current Zod v4 dependency instead of adding a second Zod v3 range.